Concurrency Control Protocolの作り方
現在までに多くのCC手法が提案されているが，どの手法も実装の差分はさておき基本的な概念は通底している．
CC手法の作り方，新手法を作る際の考え方についてまとめる．
Serializability
基本的には，VersionOrderを決定するwriteプロトコルを作り，それに従ってどのVersionを読むか，というreadプロトコルを作る，という順序になる． CSR
VersionOrderを命令の実行順序と一致させる．つまり，
$ (w_i(x_i) <_m w_j \rightarrow x_i \ll x_j | i,j \in H)
スケジュール上のwriteの順序をVersionOrderとしてedgeを張る．
となると， $ w-wの向きが規定されるので，これに$ w-rと$ r-wが反しないようにreadのプロトコルを作る．
$ w-r: コミット済みの値しか読めない制約をつけると，$ w-wと一致する．
$ r-w: ここにプロトコルの自由度がある．$ w-w, w-rと一致する，すなわちコミット順序と一致すればよい．
TicToc/MOCC/SSN/SSI/BCC...と色々やりようがある
readのプロトコルを「コミット済みの値で最新のもの」とすると1VCCとなり，更に実装が容易に． MVSR
まず，VersionOrderの決め方は自由である．
加えて，Readのプロトコル(どのVersionを読むか)も自由である．
よって，二つの項目を決定しなければならない:
writeにおけるVersionOrderの決定方法
readにおけるVersionの決定方法
これを，トランザクション開始時に割り振るタイムスタンプ等で一意に定め，全タプルについてその規則に従う，というやり方がMVTO． ただし，このように一意なトランザクションの全順序とread/writeのプロトコルを一致させる手法ははMCSRと呼ばれるクラスに分類される．例は以下 $ H = w_i(x_i)r_j(x_i)w_k(x_k)
1.$ j < kのとき: $ w_i \ll w_k ．普通に書込み
2.$ i < k < jのとき: 同じく$ w_i \ll w_k.$ T_i \to_{\ll} T_k, T_i \to_{wr} T_jでまだMVSRだが，MVTOでアボート
3.$ k < iのとき: $ w_k \ll w_i．普通に書込み
2.のケースはアボートしなくてもよいはずだが，MCSRのプロトコルであるMVTOではアボートする．
また，1. の場合($ j<k)であっても，$ w_k \ll w_iとみなしてもMVSRである．
しかし，MCSRプロトコルではこの選択は許されない．
MVSRにおいては，各read/writeのプロトコルが，タイムスタンプ等を抜きにして，各タプルについて自由にバージョンを決定できると，最大のスケジュール性能が発揮できると考えられるが，計算量は計り知れない．